At 18:29 +0200 on 22/03/1999, Richi Plana wrote:
> It kinda defeats the purpose of allowing RADIUS to fork() if I do locking.
> I've no benchmarks to prove it, but if I allow it to execute one process
> at a time via locking, that would probably slow the other processes down.
> (ie. Should the waiting process block? If so, when will it try again? Are
> the overheads to establishin a connection really that big?)
It always depends on the case in hand. You are using the current version of
postgres, not one of the snapshots, right? Well, in the current version,
any update to a table locks it, so other processes doing the same
operations are blocked anyway. If your process tree generates a lot of
children that have to write a record to the same table, it will be blocked
anyway. So why not save at least the price of starting another postgres
process and establishing a connection?
BTW, working in a three tier environment has a similar effect as locking.
It's the old "message passing" vs. "memory sharing" in disguise.
Herouth
